With the advent of parallel hardware and grid computing systems, the current trend in distributed and parallel computing industry is progressing in two paths simultaneously; one to develop applications with parallelism in place right from start and other is to exploit inherent parallelism already existing in applications. The latter challenge is more important for enterprise today where software applications in different verticals and horizontal domains are in need of tools or products that enable them to leverage the potential parallel hardware. The initial step in this process is to identify the potential areas of parallelism in the application. Loops, in general, are targets for potential parallelism. So for a programmer it is often needed to have a clear picture of the loop structure in place where each loop is associated with some metric to identify its degree of complexity with the rest of the application. Loops that are more cluttered are those which need to be analyzed for potential parallelism to ease out the execution for better performance.
The focus of software application developers who work on migrating applications to parallel hardware or grid network is to find out the portions of the code which is involving lot of computation time. Parallelizing these heavy sections of code will reduce the effective execution time and increased efficiency. Two dimensions of identifying these portions in the code exist where one is at task level. Here, modules of code needed to be analyzed for any inter-dependencies and such identified independent modules can be deployed in grid environment or parallel hardware such as multicore machines. Other dimension is at identifying heavy loops as these are most susceptible for parallel execution. Such identified heavy and potential parallel loops can be split across parallel processing units and then execute data partitions in parallel. So the initial task for the parallelizing loops is identifying loops that are heavy and show parallelistic features.
Although there are number of solutions available in the market for data parallelism but there are a number of disadvantages associated with these solutions. One of the disadvantages is that the current analysis techniques are focused on all loops present in the application irrespective of their complexity. This is time consuming as not all loops are problematic that cause bottleneck in the application execution. Manual analysis of the same is time consuming and error-prone. Further, programs designed with constructs directives to parallelize loops which can be directly detected and executed in parallel but legacy applications that were designed and implemented with no such provision pose biggest challenge in parallelizing them.
In view of the foregoing discussion, there is a need for identifying only the problematic loops in an application which can be analyzed further for potential parallelism in contrast with analyzing every loop in an application.